I have a use case where I want to combine multiple incidents into one, because it turns out they were all related to a single release being pushed to production. I want to do this because I want to include a note that identifies the release and PR that cause the incidents; Iâd rather not have to add a note to every single incident.
Combining multiple incidents
I think this may help:
Excerpt:
- Use the checkboxes to select the incidents
- Next, select Merge Incidents.
- In the popup, you can choose which incident you would like all of the alerts to be grouped under. When merging, you also have the ability to update the incident summary to more accurately reflect the problem.
- The incident dashboard will show a single incident. When you click to open the Incident and view its details, the alerts that you merged will be listed as the incident details.
Hope this helps!
Ah, thatâs exactly what I was looking for. Clearly Iâm just blind! Thanks!
No worries, glad to help!
@amaier
Hello Alex
I was trying the same feature (of incident merging). I found the following two issues:
- The merged incidents go to âRESOLVEDâ status by default.
- I couldnât see the list of incidents that got merged when I opened the parent incident (the incident I merged all the others into)
Can you please tell, what did I miss? Thank you
Hello @arpanbhagat5,
You did not miss anything. That is the expected behaviour when Incidents are
merged. Those merged incidents will point to the Parent Incident.
Please see the article on Merged Incidents here for more details.
I hope this helps.
Cheers
@Inactive-Member-99077006
Yes, I figured that out later. Thank you.
On a different topic, Can we create a workflow for a âcustomized responder assignmentâ for a service.
For example, âuser-adminâ request processing use case
- For some alert A created by an event E on service S by a user U1, we need to assign a particular user U2.
- Think of this as U1 being a developer and U2 as a leader/admin.
- This becomes a case of request approval than that of an event(issue) that has popped up in the service S
The obvious way would be to divide these unique events into separate services and assign the U2 person as required. But, for a team of 200 or so people, creating 200 services would be messy. So, any elegant solution to this?
Possible solution?
Under event rules
, we can cherrypick alerts based on a certain criteria, so we set the user name using custom details.
But, after that we canât assign someone for that selected alert.
I know the purpose of Event rule was to suppress the alerts and not create more actions out of it.
But, if we could, it would have solved the problem mentioned above.
Update : I delved into the developer.pagerduty (https://v2.developer.pagerduty.com/v2/page/api-reference#!/Incidents/post_incidents). It seems we can set assignee while creating the incident itself. Is this relevant to the use case I mentioned above?
Hello @arpanbhagat5,
Many thanks for your feedback!
Currently, Event Rules route Alerts to Services, in so doing Teams that monitor the Service.
However, I will be raising this as a Feature Request with Product Team to consider.
Thanks
@Inactive-Member-99077006
Thank you for taking the request into consideration.
I was trying a simple incident trigger using API v2.
I used the following request
$ curl -X POST --header âContent-Type: application/jsonâ --header âAccept: application/vnd.@company.comâ --header âAuthorization: Token token=y_XXXXXXXXXXXXXXXXXXXâ -d â{
âincidentâ: {
âtypeâ: âincidentâ,
âtitleâ: âCommand monitoring: Investigate cmdâ,
âserviceâ: {
âidâ: âP123456â, #My test service
âtypeâ: âservice_referenceâ
},
âurgencyâ: âhighâ,
âbodyâ: {
âtypeâ: âincident_bodyâ,
âdetailsâ: âSudo command was run. You should investigate.â
},
âassignmentsâ: {
âassigneeâ: {
âidâ: âP789123â, #my user name
âtypeâ: âuserâ
}
}
}
}â âhttps://api.pagerduty.com/incidentsâ -v
to which, I got the following message:
{âerrorâ:{âmessageâ:âAccess Deniedâ,âcodeâ:2010}}
Can you help me how to test the API commands?
Point me to some reference (about expected error codes etc.) if the need be.
Thank you
The issue here is that you are using the default token on the system when you
should have generated one on your account. For more details on this please
refer to PagerDutyâs documentation
on this subject.
Can I point out that it is not advisable to place such details regarding your account in a public
like this. If you have further details regarding this, please do email support@pagerduty.com.
Thanks
it is not advisable to place such details regarding your account in a public
Thank you for the caution. Will take care from the next time.
I understood the usage of token also. Thank you
Regards,
Arpan Bhagat